In a desktop application model, a user installing an application makes a once-and-for-all trust decision at “install time” to trust an application in its entirety. This decision is typically based on provenance of the application or a recommendation for the application. Once installed, the desktop application has the ability to see essentially any private data the user has stored, to interfere with other applications (sometimes desirably) and to capture privacy-sensitive input from a microphone, camera, location sensor or the like.
One attractive feature of a web application model, meanwhile, is that this model replaces the desktop-application trust model with a much more modest trust model. Here, each web application is isolated according to the web site that hosts the respective application, and the site name serves as a security principal. The application is isolated from other applications and from the user's stored files via a safe language mechanism (such as Java or JavaScript) or via an isolated binary container. This model eliminates the need for the user to approve each application. Instead, the user visits a site, uses an application and, when finished, the user closes the window. At this point, the application is gone from the perspective of the user's computing device, and the application has not been given access to the user's private information through the file system or other applications.
Some web applications, however, require legitimate access to privacy-sensitive input devices. A video conferencing application, for instance, reads the webcam and microphone of the user's computing device. A friends-proximity application reads the location of the computing device from the location sensor, such as a global positioning system (GPS). Because of this, the user typically determines which applications (or vendors, expressed as domains) to trust with the privacy-sensitive stream, such as the video feed, the location information or the like.
Two naïve models present themselves. Per-session authorization allows an application access to a device until the application window is closed. Repeated uses of the application result in potentially numbing dialog boxes, training the user to click “OK” without thinking, eventually eliminating any intelligent authorization decision-making by the user.
Alternatively, trust can be associated with the principal (e.g., with a web site domain) that supplies the application. Here, future instances of the same application, and even revisions of the application, work without explicit reauthorization. In this world, the access control list that enumerates the “trusted principals” is buried in the browser of the user's computing device. Few users will ever locate or see this list of accepted domains, memorize the list of domains, and understand how those domains map (via the address bar) to the actual applications the users run. As such, this model also presents a security risk in the form of nearly unlimited trust being given to a principal (e.g., a web site domain) to whom the user should in fact not provide such open-ended trust.